Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use distinctive names for SPI pin macros to avoid collisions #71

Merged
merged 2 commits into from
Dec 30, 2023

Conversation

per1234
Copy link
Contributor

@per1234 per1234 commented Dec 30, 2023

The "ArduinoISP" example allows the user to define arbitrary pins for use as the signal pins on the programmer board. This is done via a set of macros.

Previously, very generic names were used for these macros. This resulted in a name collision. The core for the Renesas boards also defines macros of the same name:

https://github.com/arduino/ArduinoCore-renesas/blob/1.0.5/cores/arduino/variant.h#L48-L50

#define PIN_MISO                    (6 << PIN_USE_POS)
#define PIN_MOSI                    (7 << PIN_USE_POS)
#define PIN_SCK                     (8 << PIN_USE_POS)

Despite what the names might lead us to believe, the values of these macros in the core do not match the Arduino pin numbers of the SPI bus. The result was that, with the default configuration of the sketch where the USE_OLD_STYLE_WIRING macro is not defined:

the sketch uses the values of the macros defined by the core as the SPI signal pins instead of the standard SPI signal pins as the user would expect when the sketch is running on an UNO R4 Minima, UNO R4 WiFi, or Portenta C33 board. This causes operations using the programmer to fail with an error like:

avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03 [...]

The name collision is avoided by adding a "namespace" prefix to the macro names.

Additional Context

Originally reported at https://forum.arduino.cc/t/can-i-use-the-r4-minima-as-an-icsp/1170056

The repository infrastructure includes a GitHub Actions workflow that compiles the examples for significant official
Arduino boards. This provides a automated "smoke test" to easily get some basic validation of the sketches.

Since the time the workflow was created, several new official boards have been released. Some of these boards are
significantly different from the boards the workflow was compiling the examples for, which meant the workflow was not
providing adequate coverage for the new boards.

The workflow is hereby configured to also compile the examples for the significant new boards.
The "ArduinoISP" example allows the user to define arbitrary pins for use as the signal pins on the programmer board.
This is done via a set of macros.

Previously, very generic names were used for these macros. This resulted in a name collision. The core for the Renesas
boards also defines macros of the same name. Despite what the names might lead us to believe, the values of these macros
in the core do not match the Arduino pin numbers of the SPI bus. The result was that, with the default configuration of
the sketch where the USE_OLD_STYLE_WIRING macro is not defined, the sketch uses the values of the macros defined by the
core as the SPI signal pins instead of the standard SPI signal pins as the user would expect when the sketch is running
on an UNO R4 Minima, UNO R4 WiFi, or Portenta C33 board. This causes operations using the programmer to fail with an
error like:

avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03
[...]

The name collision is avoided by adding a "namespace" prefix to the macro names.
@per1234 per1234 added type: imperfection Perceived defect in any part of project topic: code Related to content of the project itself labels Dec 30, 2023
@per1234 per1234 self-assigned this Dec 30, 2023
@per1234 per1234 merged commit 1d7b1fb into arduino:main Dec 30, 2023
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant